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I. Introduction 

This is an Appeal Brief under 37 C.F.R. § 41.37 appealing the rejections set forth 
in the Office action dated November 16, 2009. Each of the topics required by 37 C.F.R. 
§ 41.37 is presented in this Brief and is labeled appropriately. 
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II. Real Party in Interest 
Honeywell International, Inc. ("Honeywell") is the real party in interest of the 
present application. An assignment of all rights in the present application to Honeywell 
was executed by the inventors and recorded by the U.S. Patent and Trademark Office at 
Reel 014342, Frame 0163. 



III. Related Appeals and Interferences 
There are no appeals or interferences related to the present application of which 
Appellant is aware. 
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IV. Status of Claims 
Claims 1, 6-15, 20-28, 37, and 42-49, which are presented in the Claims 
Appendix, are pending in the application. Each of Claims 1, 6-15, 20-28, 37, and 42-49 
stand rejected, each of Claims 2-5, 16-19, 29-36, and 38-41 have been canceled. 
5 Accordingly, the Appellant hereby appeals the final rejection of Claims 1, 6-15, 20-28, 
37, and 42-49. 
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V. Status of Amendments 
No amendments following the final Office action of November 16, 2009 have 
been filed. 
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VI. Summary of Claimed Subject Matter 
The subject matter of independent Claim 1 relates to a program product that 
includes a database (110) and at least one physical computer-readable medium (112). 
The database (110) is compatible with multiple end-user systems (102-1, 102-2, 102-3 . . 
5 . 102-N) and includes a data section (306) and a structure section (304) (pg. 6, 11. 18-30; 
pg. 8, 11. 4-9; FIG. 3). The data section (306) comprises a plurality of data tables (212-1, 
202-2, 202-3 . . . 202-N)) that each include a plurality of data records (204-1, 204-2, 204- 
3 . . . 204-N) (pg. 8, 11. 6-9). Each data record has one or more features that affect its 
compatibility with one or more of the end-user systems (pg. 6, 11. 25-27; pg. 7, 11. 6-8). 

10 Each data record also includes a feature field (206-2) that contains one or more feature 
bits representative of each of its features (pg. 7, 11. 8-14; FIG. 2). The structure section 
(304) comprises a plurality of feature mask tables (602-4) that each include a feature 
mask record (1004-1, 1004-2, 1004-3 . . . 1004-N) for each of the multiple end-user 
systems that use one or more of the data tables that include the data records having one or 

15 more features (pg. 10, 11. 17-23; FIGS. 2, 3, 10). Each feature mask record includes one 
or more feature mask values that indicate whether a particular one of the data records is 
the one or more features of a data record are compatible with one or more of the end-user 
systems, and thereby indicate whether the data record is compatible with one or more of 
the end-user systems (pg. 7, 11. 21-27; pg. 10, 1. 29-pg. 8, 1. 6; FIGS. 2, 3, 10). The at 

20 least one physical computer-readable medium has the database stored thereon (pg. 6, 11. 
8-9; FIG. 1). 
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The subject matter of independent Claim 15 relates to a method of generating a 
database (110) that is compatible with multiple end-user systems (102-1, 102-2, 102-3, . . 
. 102-N), and includes the method comprising the steps of generating a data section (306) 
and storing a plurality of data records (204-1, 204-2, 204-3 . . . 204-N) in the data section 
5 (pg. 8, 11. 6-9). Each data record includes a feature field (206-2), and one or more 

features is associated with each data record (pg. 6, 11. 25-29, pg. 7, 11. 6-8). Each feature 
field is with one or more feature bits that represent each of the features associated 
therewith (pg. 7, 11. 8-14; FIG. 2). The data section is divided into a plurality of data 
tables (201-1, 201-2, 201-3 .. . 201-N) that each include a plurality of the data records 

10 (pg. 8, 11. 6-9). A data structure section (304) is generated that comprises a plurality of 
feature mask tables (602-4) that each include a feature mask record (1004-1, 1004-2, 
1004-3 . . . 1004-N) for each of the end-user systems that use one or more of the data 
tables that include the data records having one or more features (pg. 10, 11. 17-23; FIGS. 
2, 3, 10). One or more feature mask values are included, in each feature mask record, 

15 that indicate whether a particular one of the stored data records is the one or more 
features of a data record are compatible with one or more of the end-user systems, to 
thereby indicate whether the data record is compatible with one or more of the end-user 
systems (pg. 7, 11. 21-27; pg. 10, 1. 29-pg. 8, 1. 6; FIGS. 2, 3, 10). 

20 The subject matter of independent Claim 37 relates to a computer system (100) 

that includes a processor (104), memory (1 12) in operable communication with the 
processor, and a database (1 10). The database is stored in the memory (pg. 6, 11. 8-9), is 
compatible with multiple end-user systems (102-1, 102-2, 102-3, . . . 102-N) (pg. 6, 11. 
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18-30), and includes a data section (306) and a structure section (304) (pg. 8, 11. 1-2; FIG. 
3). The data section (306) comprises a plurality of data tables (212-1, 202-2, 202-3 . . . 
202-N)) that each include a plurality of data records (204-1, 204-2, 204-3 . . . 204-N) (pg. 
8, 11. 6-9). Each data record has one or more features that affect its compatibility with 
5 one or more of the end-user systems (pg. 6, 11. 25-27; pg. 7, 11. 6-8). Each data record 
also includes a feature field (206-2) that contains one or more feature bits representative 
of each of its features (pg. 7, 11. 8-14; FIG. 2). The structure section (304) comprises a 
plurality of feature mask tables (602-4) that each include a feature mask record (1004-1, 
1004-2, 1004-3 . . . 1004-N) for each of the multiple end-user systems that use one or 

10 more of the data tables that include the data records having one or more features (pg. 10, 
11. 17-23; FIGS. 2, 3, 10). Each feature mask record includes one or more feature mask 
values that indicate whether a particular one of the data records is the one or more 
features of a data record are compatible with one or more of the end-user systems, and 
thereby indicate whether the data record is compatible with one or more of the end-user 

15 systems (pg. 7, 11. 21-27; pg. 10, 1. 29-pg. 8, 1. 6; FIGS. 2, 3, 10). 

The subject matter of independent Claim 49 relates to a flight management 
system that includes memory (1 12), a navigation database (110), and a processor (104). 
The navigation database is stored in the memory (pg. 6, 11. 8-9), is compatible with 
20 multiple flight management systems (pg. 6, 11. 18-30), and includes a data section (306) 
and a structure section (304) (pg. 8, 11. 1-2; FIG. 3). The data section (306) comprises a 
plurality of data tables (212-1, 202-2, 202-3 . . . 202-N)) that each include a plurality of 
navigational data records (204-1, 204-2, 204-3 . . . 204-N) (pg. 8, 11. 6-9). Each 



navigational data record has one or more features that affect its compatibility with one or 
more of the flight management systems (pg. 6, 11. 25-27; pg. 7, 11. 6-8). Each data record 
also includes a feature field (206-2) that contains one or more feature bits representative 
of each of its features (pg. 7, 11. 8-14; FIG. 2). The structure section (304) comprises a 
5 plurality of feature mask tables (602-4) that each include a feature mask record (1 004- 1 , 
1004-2, 1004-3 . . . 1004-N) for each of the multiple end-user systems that use one or 
more of the data tables that include the data records having one or more features (pg. 10, 
11. 17-23; FIGS. 2, 3, 10). Each feature mask record includes one or more feature mask 
values that indicate whether the one or more features of a navigational data record are 
10 compatible with one or more of the flight management systems, and thereby indicate 

whether the data record is compatible with one or more of the flight management systems 
(pg. 7, 11. 21-27; pg. 10, 1. 29-pg. 8, 1. 6; FIGS. 2, 3, 10). The processor is configured to 
generate an aircraft flight plan based at least in part on the navigational data stored in the 
navigation database (pg. 1, 11. 13-25; pg. 23, 11. 9-10). 
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VII. Grounds of Rejection to be Reviewed on Appeal 
The grounds of rejection to be reviewed in this appeal are as follows: 



1. Whether Claims 1, 6, 7, 1 1, 15, 20, 21, 25, 37, 42, 43, and 47 are 

5 unpatentable under 35 U.S.C. § 103 over U.S. Patent Nos. 6,804,664 ( Hartman et al. ). 
5,710,915 ( McElhinev ) 

2. Whether Claims 8-10, 12-14, 22-24, 26-28, and 44-48 are unpatentable 
under 35 U.S.C. § 103 over, Hartman et al. . McElhinev . and U.S. Patent No. 5,201,046 

10 (Goldberg et al) . 

3. Whether Claim 49 is unpatentable under 35 U.S.C. § 103 over, Hartman et 
al, McElhinev . Goldberg et al. and U.S. Patent No. 6,134,500 ( Tang et al ). 

15 
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VIII. Arguments 



I. CLAIMS 1,6,7, 11, 15,20,21,25,37,42,43, AND 47 ARE NOT 

UNPATENTABLE UNDER 35 U.S.C. § 103 OVER HARTMAN ET AL. 
5 AND McELHINEY 



A. Hartman et al. 

Hartman et al. relates to a database that is structured to enable faster, more 
efficient queries. To do so, the data to be stored in the database is characterized as a 

10 number of questions, and each record in the database comprises bit map groups that 

correspond to the answers to the questions. The answers may be binary attributes, range 
attributes, and string attributes, depending on the question type. With this type of 
structure, database queries are obtained by simple bit-wise Boolean operations of the 
records in the database, beginning first with binary attribute matching, then range 

15 attribute matching, and finally string attribute matching. With each attribute matching 
operation, various of the records in the database are eliminated from the query, thus 
making the query more efficient (col. 8, 1. 9 through col. 12, 1. 1 1). 



B. McElhiney 

20 McElhiney relates to a system and method to easily store and manipulate data in a 

relational database system, preferably by implementing what is referred to as "transitive 
closures" (col. 3, 1. 63 through col. 4, 1. 42). McElhiney discloses, in the Abstract, a 
database management system (DBMS) that stores, retrieves, and manipulates directed 
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graph data structures in a relational database. Data are stored in a database in the form of 
two dimensional tables, which are referred to as flat files. The DBMS defines a schema 
for each table in the database. The schema defines the name and data type of each 
column in a database table. Tables that are used to store directed graph data structures 
5 include at least one column defined as having a reference data type. Non-empty entries 
in that column are pointers to rows in a specified table. Directed graph data structures are 
stored in specified tables by storing each record of the directed graph in a distinct row of 
one of the specified tables, with references corresponding to interconnections between 
records being stored in reference data type columns. Portions of a directed graph are 

10 retrieved from the specified table, in accordance with a single specified query and then 
the query is automatically expanded by also retrieving additional portions of the tables 
which are referenced by the previously retrieved portions, thereby performing a transitive 
closure. The retrieved data is stored in a buffer as a list of rows, and then communicated 
to an application process. An interface program converts the list of rows stored in the 

15 buffer into a directed graph data structure. 

C. The Final Office Action 

The final Office action alleges that Hartman et al. discloses a database that is 
compatible with multiple end-user systems. The Office action further alleges that the 
20 content database of Hartman et al. corresponds, at least generally, to the data section of 
independent Claims 1, 15, 37, and 49 of the instant application, and cites col. 4, 11. 35-46, 
col. 6, 11. 19-24, and col. 7, 11. 39-48 to support this allegation. The Office action also 
alleges that Hartman et al. discloses, at least generally, the structure section of 
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independent Claims 1, 15, 37, and 49 of the instant application, and cites col. 6, 11. 25-38, 
col. 7, 11. 16-26, and col. 8, 11. 9-18 and 54-64 to support this allegation. The Office 
action then goes on to opine that the only deficiency of Hartman et al. is that it does not 
disclose that the data section and the structure section each comprise a plurality of tables. 
5 To make up for the allegedly sole lacuna of Hartman et al, the Office action cites 

McElhiney. Specifically, the Office action cites col. 7, 11. 49-58 of McElhiney as 
disclosing "the partitioning of a data table into a plurality of tables." The Office action 
then goes on to conclude that it would have been obvious "to partition the data section 
and the structure sections of Hartman into a plurality of tables ... to provide parallel 
10 access to the tables which accelerates access." Office action at 4-5. As will now be 

explained, the analysis proffered in the Office action is inaccurate, in that Hartman et al. 
does not disclose all that is alleged in the Office action. Furthermore, the combination of 
Hartman et al. and McElhiney does not establish a prima facie case of obviousness. 

15 D. Analysis 

The Examiner bears the initial burden of establishing a prima facie case of 
obviousness. In re Fine , 837 F.2d 1071, 1074 (Fed. Cir. 1988). As such, the Examiner 
has the burden of setting forth a detailed evidentiary basis for the teaching, suggestion or 
motivation to combine the cited references. Indeed, as the Supreme Court recently 

20 reiterated, it is "important to identify a reason that would have prompted a person of 
ordinary skill in the relevant field to combine the elements in the way the claimed new 
invention does." KSR International Co. v. Teleflex Inc. , 127 S. Ct. 1727, 1741 (2007). 
The mere allegation that references can be combined or modified does not render the 
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alleged combination obvious unless the result would have been predictable to the 
ordinarily skilled artisan. Id. 

A claim cannot be found prima facie obvious unless all of the claim elements are 
either taught or suggested in the cited art or form part of the knowledge of one of 
5 ordinary skill in the art, or all of claim elements are obvious from the nature of the 

problem itself. In re Dembiczak . 175 F.3d 994, 999 (Fed. Cir. 1999) (emphasis added); 
In re Wilson , 424 F.2d 1382, 1385 (C.C.P.A. 1970) ("All words in a claim must be 
considered in judging the patentability of that claim against the prior art."). The Board of 
Patent Appeal and Interferences recently confirmed this principle, stating that a proper 

10 obviousness determination requires "a searching comparison of the claimed invention - 
including all its limitations - with the teaching of the prior art." Sec In rc Wada and 
Murphy . Appeal 2007-3733, citing In re Ochiai, 71 F.3d 1565, 1572 (Fed. Cir. 1995) 
(emphasis in original). Further, the necessary presence of all claim features is axiomatic, 
since the Supreme Court has long held that obviousness is a question of law based on 

15 underlying factual inquiries, including ascertaining the differences between the claimed 
invention and the prior art. Graham v. John Deere Co. . 383 U.S. 1, 148 USPQ 459 (1966) 
(emphasis added). 

In sum, it remains well-settled law that obviousness requires at least a suggestion 
of all of the features in a claim. See In re Wada and Murphy , citing CFMT, Inc. v. 
20 Yieldup Intern. Corp. . 349 F.3d 1333, 1342 (Fed. Cir. 2003) and In re Rovka . 490 F.2d 
981,985 (CCPA 1974)). 

Moreover, it is well-settled that, in order to avoid succumbing to the temptation of 
reliance on hindsight, the teaching or suggestion to make the claimed combination must 
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not be found in an applicant's disclosure. In re Vaeck , 947 F.2d 488, 20 USPQ2d 1438 
(Fed. Cir. 1991). Although it is recognized that any determination of obviousness is, in a 
sense, based on hindsight reasoning, if the determination does not take into account only 
knowledge within the level of ordinary skill in the art at the time the claimed invention 
5 was made, but relies on knowledge gleaned only from an applicant's own disclosure, then 
hindsight has been impermissibly applied. In re McLaughlin , 443 F.2d 1392, 1395, 170 
USPQ 209, 212 (CCPA 1971). 

Appellant submits that the Examiner has not met her burden in establishing a 
prima facie case of obviousness because the prior art does not objectively teach or 
10 suggest all of the recited claim elements, nor are all of the recited claim elements obvious 
from the nature of the problem itself. As such, it is submitted that the Examiner is 
unwittingly relying on impermissible hindsight reasoning. 



1. Hartman et al. Does Not Disclose the Claimed Data Section 
15 As was noted above, the Office action alleges that that the content databases (150, 

151, 152) of Hartman et al. correspond to the claimed data section. The Office action 
references col. 4, 11. 35-46, col. 6, 11. 19-24, and col. 7, 11. 39-48 to support this allegation. 

Interestingly, if one reviews the above-noted portions of Hartman et al, it is 
readily apparent that these portions do not even remotely address the content databases 
20 (150, 151, 152). More significantly, however, according to the independent claims of the 
instant application: (1) each data table that comprises the data section includes a plurality 
of data records that each have one or more features that affect its compatibility with one 
or more of the end-user systems, and (2) each data record includes a feature field that 
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contains one or more feature bits representative of each of its features. Although 
Hartman et al. discloses looking up fields in the correlation table and retrieving bitmasks 
for the attributes corresponding to the fields, nowhere does Hartman et al. disclose, in 
those portions referenced in the final Office action or any other portion, data records 
5 having one or more features that affect compatibility with one or more of end-user 

systems or data records that include a feature field that contains one or more feature 
bits representative of each of its features. 

In the Response to Arguments section of the final Office action, the Examiner 
attempts to rebut the above argument by alleging that col. 6, 11. 25-38 of Hartman et al. 

10 discloses that the user profile database stores information regarding users and about client 
devices, and that that col. 5, 11. 3-14 and 25-33 disclose that a binary attribute is compared 
to the profile. Based on this, the Examiner makes the conclusory statement that because 
"the profile information can be device information, the records can be filtered based on 
compatibility." This statement is erroneous, and thus so is the conclusion. 

15 First of all, the allegation that Hartman et al. discloses that the profile information 

"can be" device information mischaracterizes what is actually disclosed. If Hartman et 

al. did provide such a teaching, this might lead one to conclude that, at least in some 

embodiments, Hartman et al. contemplated the profile information including only device 

information. 1 However, what col. 6, 11. 25-38 actually states is: 

20 "Information about the client devices used by each user, such as type of 

device and processing capabilities, may also be obtained and stored in the user 
profile database 140 or another database." 



1 Applicants, of course, do not concede this as an admission of a finding of fact. 
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Thus, what is actually disclosed is that the profile information may additionally include 
device information, and not that profile information, in its entirety, may be device 
information. 

Secondly, although Hartman et al. does disclose storing user profile data and 
5 client profile data, and that user profiles may refer to client profiles, and vice-versa, the 
reason for doing so is because multiple users may use a particular client, and a particular 
user may use multiple clients. This has nothing whatsoever to do with data records 
having features that affect the compatibility of a data record with an end-user system. 
Rather, this deals with whether a user, via a specific client, may access certain data. As 

10 has been stated repeatedly during the prosecution of this application, accessibility to data 
by a device or system, and compatibility of data with a device or system, are completely 
different issues. It is the former at which, at best, Hartman et al. even hints. 

Applicants submit that the Examiner is conflating, within the paradigm of the 
claimed technology, the plain and ordinary meanings of "compatibility" and 

15 "accessibility." Specifically, the plain and ordinary definition for compatibility, in the 
context of the claimed invention, is: (of software) capable of being run on another 
computer without change. 2 According to the same source, 3 accessibility has the 
following common meanings: (1) easy to approach, reach, enter, speak with, or use; (2) 
that can be used, entered, reached, etc.; (3) obtainable; attainable; and (4) open to the 

20 influence of (usually fol. by to). In the context of Hartman et al, either the second 

1 Institute of Electrical and Electronics Engineers (IEEE): Dictionary.com, "compatibility," in 
Dictionaiy.com Unabridged. Source location: Random House, Inc. Available: 

h 1 1 p : di ctionary .reference. com . Accessed: February 12, 2010. 

2 Dictionary.com, "accessibility," in Dictionary.com Unabridged. Source location: Random House, Inc. 
Available: hrtp://dict ionary.reference.com . Accessed: February 12, 2010. 
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definition (that can be used, entered, reached, etc.) or the third definition (obtainable; 
attainable) fit, as it refers to the ability to use, reach, or obtain data. 

2. Hartman et al. Does Not Disclose the Claimed Structure Section 

5 The final Office action also alleges that Hartman et al. discloses a structure 

section. The Office action references col. 6, 11. 25-38, col. 7, 11. 16-26, and col. 8, 11. 9-18 

and 54-64 to support this allegation. 

According to each of the independent claims: (1) each feature mask table that 

comprises the structure section includes a feature mask record for each of the multiple 

10 end-user systems that use one or more of the data tables that include the data records 

having one or more features, and (2) each feature mask record includes one or more 

feature mask values that indicate whether the one or more features of a data record are 

compatible with one or more of the end-user systems, and thereby indicate whether the 

data record is compatible with one or more of the end-user systems. 

15 In the final Office action, the Examiner alleges that the content of each feature 

mask record, as delineated above, is disclosed at col. 8, 11. 9-18 and 11. 54-61 of Hartman 

et al. Appellant notes that col. 8, 11. 9-18 of Hartman et al. states: 

"As described below, the method of querying a database is a reductive 
process. In a typical database query, the fields of each record of the database is 

20 compared in turn against the query. If the fields of a record match the query, then 

the record is added to a list of matching records. A typical database query is 
therefore an additive process. According to the invention, a query is structured to 
benefit from how the data is stored (as described above), and how a query may be 
best processed. The present invention may also be considered a successive 

25 filtering process."; 

and col. 8, 11. 54-61 states: 
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"In the binary attribute matching step (step 340), the binary attributes of 
the query profile are matched against the binary attributes in the query database. 
For example, if the query profile is based upon a user profile from the user profile 
database 140, then the query profile would be matched against the content profiles 
5 in the content profile database 1 50. Matching may be accomplished through 

binary operations, such as logical AND." 

Appellant submits that neither of these sections of Hartman et al. (nor any other 
portion, for that matter) disclose, or even remotely suggest, that each feature mask record 
10 in a feature mask table includes one or more feature mask values that indicate whether 
the one or more features of a data record are compatible with one or more of the end-user 
systems, and thereby indicate whether the data record is compatible with one or more of 
the end-user systems. 

Appellant also notes that the Examiner failed to address the above argument in the 
15 final Office action. It is submitted that this is because the argument cannot be rebutted. 



3. McElhiney Does Not Disclose or Suggest All That is Alleged 

McElhiney was cited in the final Office action for allegedly disclosing, at col. 7, 

11. 49-58, the "partitioning of a data table into a plurality of tables." Final Office action at 

20 4. This portion of McElhiney states: 

"After building the database structure, records are added to the search and detail 
tables of the database. As records are inserted, the system tests to determine if the number 
of records exceeds a predetermined threshold number, for example 50,000 records. When 
this threshold is exceeded, both the search and detail tables are partitioned, i.e. split into 
25 two sub-tables each. This threshold is tunable, based upon the size of the database and the 
size and number of disks in the computer system. When possible, the two sub-tables are 
placed on separate physical storage devices." 

It is quite clear from the above that McElhiney merely discloses storing data in a 
30 database in the form of two-dimensional tables, and splitting each of the tables into sub- 
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tables if the number of records exceeds some threshold. This is wholly disparate from 
providing data sections and structure sections that comprise a plurality of data tables and 
feature mask tables, respectively. Nonetheless, even if one were to concede that 
McElhiney discloses what the Office action alleges, 4 it does not make up for the rather 
5 glaring deficiencies of Hartman et al. with respect to the independent claims. 

4. The Independent Claims are Not Obvious 

In view of the foregoing, Appellant submits that the combination of Hartman et 
al. and McElhiney does not, and indeed cannot, establish a prima facie case of 
10 obviousness of any one of independent Claims 1,15, 37, or 49. This is because the 
alleged combination of references fails to disclose each and every element recited in 
these claims. As such, there can be no teaching, suggestion, or motivation that would 
have led one of ordinary skill to combine these reference teachings to arrive at the 
claimed invention. 

15 Moreover, the Examiner has not provided a factual basis or articulated reasoning 

that the inventions encompassed by the independent claims have resulted from: (1) 
combining prior art elements according to known methods to yield predictable results; (2) 
a simple substitution of one known element for another to obtain predictable results; (3) 
using a known technique to improve similar devices (methods, or products) in the same 

20 way; (4) applying a known technique to a known device (method, or product) ready for 
improvement to yield predictable results; (5) choosing from a finite number of identified, 
predictable solutions, with a reasonable expectation of success (e.g., "obvious-to-try); or 

4 Applicants, of course, do not concede this point. 
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(6) known work in one field of endeavor that prompted variations of it for use based on 
design incentives or other market forces if the variations are predictable to one of 
ordinary skill in the art. 

5 5. The Dependent Claims Are Also Not Obvious 

Because independent Claims 1, 15, and 37 are not obvious, then dependent 
Claims 6, 7, 1 1, 20, 21, 25, 42, 43, and 47 are also believed not obvious. In re Fine , 
supra. However, as will now be explained, the features recited in each of these 
dependent claims is also not disclosed or suggested by Hartman et al. and McElhiney. 

10 

a. Dependent Claims 6, 20, and 42 
Dependent Claims 6, 20, and 42 each recite that the structure section further 
comprises a system identification table that includes data that uniquely identifies each of 
the end-user systems. The final Office action cites col. 6, 11. 25-38 and col. 7, 11. 16-26 of 
15 Hartman et al. as allegedly disclosing this feature. As noted above, col. 6, 11. 25-38 
states: 

"Information about the client devices used by each user, such as type of 
device and processing capabilities, may also be obtained and stored in the user 
profile database 140 or another database." 

20 

Moreover, col. 7, 11. 16-26 states: 

"The client profile database 170 stores and provides profiles of client 
devices 100. Client profiles may include such information a software versions, 
processor type, processor speed, memory size, modem type, etc. The client profile 
25 database 170 is related to the user profile database 140, in that the profiles of 

client devices 100 used by the users are stored in the client profile database 170. 
User profiles may refer to client profiles, and client profiles may refer to user 
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profiles. This is because a given client may be used by multiple users, and a given 
user may use multiple client devices." 



Although the client profile database of Hartman et al. may include profiles of 
5 client devices, there is no teaching or suggestion of including such information in a 

separate system identification table with a structure section. Moreover, this data may not 
"uniquely identify" each client device, since one or more users may have substantially 
identical client devices (e.g., software versions, processor type, processor speed, memory 
size, modem type, etc.). 
10 For at least this additional reason, dependent Claims 6, 20, and 42 are not 

obvious. 



b. Dependent Claims 7, 21. and 43 
Dependent Claims 7, 21, and 43 recite that the system identification table 
15 comprises a plurality of system identification records, and that each system identification 
record is associated with each of the end-user systems. The final Office action again cites 
col. 6, 11. 25-38 and col. 7, 11. 16-26 of Hartman et al. as allegedly disclosing this feature. 
As may be readily apparent from the reproductions of these sections above, Hartman et 
al. does not disclose, or even remotely suggest, this additional feature. 
20 For at least this additional reason, dependent Claims 7, 21, and 43 are not 

obvious. 
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c. Dependent Claims 1 1, 25, and 47 
Dependent Claims 1 1, 25, and 47 recite that each data record includes a plurality 
of fields in addition to the feature field, and that the structure section further comprises a 
field definition table that includes at least data representative of each of the data record 
5 fields. The final Office action cites col. 7, 11. 36-38 and col. 4, 11. 35-46 of Hartman et al. 
as allegedly disclosing the former feature, and col. 7, 11. 39-42 as allegedly disclosing the 
latter feature. 

Col. 4, 11. 35-46 of Hartman et al. merely discloses that the database is built from 
records, profiles, targets, and attributes, and also defines each of these terms. At col. 7, 11. 

10 36-42, Hartman et al. discloses that when fields correspond to binary attributes, the 

database server looks up the fields in the correlation table and retrieves the bitmask for 
the binary attributes corresponding to the field. For range attributes and string attributes, 
some processing may be conducted prior to storing, and the retrieved bitmask, plus the 
values of the range attributes and string attributes, form one or more profiles of the 

15 record. 

Appellant submits that these sections of Hartman et al. do not disclose, or even 
remotely suggest, the additional features recited in dependent Claims 1 1, 25, and 47, and 
for at least this additional reason these claims are not obvious. 
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II. CLAIMS 8-10, 12-14, 22-24, 26-28, AND 44-48 ARE NOT 

UNPATENTABLE UNDER 35 U.S.C. § 103 OVER HARTMAN ET 
AL., McELHINEY, AND GOLDBERG ET AL. 

A. Hartman et al. and McElhiney 

These references were described above, and the descriptions thereof will not be 
repeated. 

B. Goldberg et al. 

Goldberg et al. relates to a database management system and method for storing, 
retrieving, and manipulating directed graph data structures in a relational database. 

C. Dependent Claims 8. 22. and 44 

Dependent Claims 8, 22, and 44 each recite that the data section comprises a 
plurality of data tables that each include a plurality of the data records, and that the 
structure section further comprises a table pointer table that includes data that uniquely 
describes at least each of the data tables. The Examiner, in the final Office action, 
concedes that neither Hartman et al. nor McElhiney disclose or suggest this feature, but 
alleges that Goldberg et al, at col. 14, 11. 31-54, does disclose this feature. 

The above-cited section of Goldberg et al. discloses a technique to avoid storing 
duplicate copies of rows or records, either while retrieving data from the database or 
storing a directed graph for transportation to the database. According to the disclosed 
technique, for each row that is stored in a buffer, an entry is made in a hash table that 
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contains various data. These data include a unique row or record identifier, a pointer to 
the corresponding table definition in a table definition section of the buffer, a pointer to 
the row as stored in the fixed format data section of the buffer, and a link field for 
sequentially accessing all entries in the hash table in the same order that the entries were 
5 added to the hash table. Before storing each row or record in the buffer, the hash table is 
checked to see if there is already an entry for that row or record. 

Appellant submits that this section of Goldberg et al. fails to disclose or even 
remotely suggest at least the additional features of dependent Claims 8, 22, and 44, let 
alone cure the deficiencies of Hartman et al. and McElhiney with respect to the claims 
10 from which these claims depend. For at least this additional reason these dependent 
claims are not obvious. 



D. Dependent Claims 9. 23. and 45 

Dependent Claims 9, 23, and 45 each recite that the table pointer table comprises 
15 a plurality of table pointer records, and that at least one table pointer record is associated 
with each of the data tables. The Examiner, in the final Office action, concedes that 
neither Hartman et al. nor McElhiney disclose or suggest this feature, but alleges that 
Goldberg et al, at col. 14, 11. 31-54, does disclose this feature. 

The above-cited section of Goldberg et al. was summarized above, and Appellant 
20 submits that this section of Goldberg et al. fails to disclose or even remotely suggest at 
least the additional features of dependent Claims 9, 23, and 45, let alone cure the 
deficiencies of Hartman et al. and McElhiney with respect to the claims from which these 
claims depend. For at least this additional reason these dependent claims are not obvious. 
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E. Dependent Claims 10. 24. and 46 

Dependent Claims 10, 24, and 46 each recite that each table pointer record 
includes data representative of at least a location of the associated data table, a number of 
the data records in the associated table, and a size of each data record in the associated 
5 data table. The Examiner concedes that neither Hartman et al. nor McElhiney disclose or 
suggest this feature, but again alleges that Goldberg et al, at col. 14, 11. 31-54, does 
disclose this feature. 

The above-cited section of Goldberg et al. was summarized above, and Appellant 
submits that this section of Goldberg et al. fails to disclose or even remotely suggest at 
10 least the additional features of dependent Claims 10, 24, and 46, let alone cure the 

deficiencies of Hartman et al. and McElhiney with respect to the claims from which these 
claims depend. For at least this additional reason these dependent claims are not obvious. 



F. Dependent Claims 12. 26. and 48 

15 Dependent Claims 12, 26, and 48 each recite that the structure section further 

comprises one or more return type tables that each include data representative of a format 
of each of the data record fields. The Examiner, in the final Office action, concedes that 
neither Hartman et al. nor McElhiney disclose or suggest this feature, but alleges that 
Goldberg et al, at col. 6, 11. 33-41, col. 1 1, 11. 37-59, and col. 13, 11. 51-62, does disclose 

20 this feature. 

The above-cited sections of Goldberg et al. discloses the definition of DATA 
TYPE (col. 6, 11. 33-41), describes the schema for a table (col. 1 1, 11. 37-59), and 
describes the table definition section (col. 13, 11. 51-62). Appellant submits that these 
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sections of Goldberg et al. fail to disclose or even remotely suggest at least the additional 
features of dependent Claims 12, 26, and 48, let alone cure the deficiencies of Hartman et 
al. and McElhiney with respect to the claims from which these claims depend. For at 
least this additional reason these dependent claims are not obvious. 

5 

G. Dependent Claims 13 and 27 

Dependent Claims 13 and 27 each recite a header section that includes data 
representative of indicia that is used to identify the database. The Examiner concedes 
that neither Hartman et al. nor McElhiney disclose or suggest this feature, but again 

10 alleges that Goldberg et al., at col. 6, 11. 33-41, col. 1 1, 11. 37-59, and col. 13, 11. 51-62, 
does disclose this feature. 

The above-cited sections of Goldberg et al. were summarized above, and 
Appellant submits that these sections of Goldberg et al. fail to disclose or even remotely 
suggest at least the additional features of dependent Claims 13 and 27, let alone cure the 

15 deficiencies of Hartman et al. and McElhiney with respect to the claims from which these 
claims depend. For at least this additional reason these dependent claims are not obvious. 

H. Dependent Claims 14 and 28 

Dependent Claims 14 and 28 each recite that the header section further includes 
20 data representative of a location of the structure section. The Examiner concedes that 
neither Hartman et al. nor McElhiney disclose or suggest this feature, but again alleges 
that Goldberg et al, at col. 6, 11. 33-41, col. 1 1, 11. 37-59, and col. 13, 11. 51-62, does 
disclose this feature. 
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The above-cited sections of Goldberg et al. were summarized above, and 
Appellant submits that these sections of Goldberg et al. fail to disclose or even remotely 
suggest at least the additional features of dependent Claims 14 and 28, let alone cure the 
deficiencies of Hartman et al. and McElhiney with respect to the claims from which these 
5 claims depend. For at least this additional reason these dependent claims are not obvious. 
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III. 



CLAIM 49 IS NOT UNPATENTABLE UNDER 35 U.S.C. § 103 OVER 



HARTMAN ET AL., McELHINEY, GOLDBERG ET AL., AND TANG 



ETAL. 



A. 



Hartman et al., McElhiney, and Goldberg et al. 



5 



These references were described above, and the descriptions thereof will not be 



repeated. 



B. Tang et al. 

Tang et al. relates to a system and method for generating a minimum-cost airline 
10 flight plan from a point of origin through a set of fix points to a destination point. 

C. Analysis 

Independent Claim 49 is commensurate in scope with the other independent, but 
is narrowly recited to the context of a flight management system and specifies navigation 

15 data. As noted above, none of Hartman et al., McElhiney, or Goldberg et al, either alone 
or in combination, is understood to disclose or suggest all of the features recited in any of 
the independent claims. Moreover, without conceding that Tang et al. discloses or 
suggests what the examiner alleges in the final Office action, upon review of this 
reference, Appellant submits that it also fails to disclose or suggest all of these features. 

20 In view of the foregoing, Appellant submits that the combination of Hartman et 

al, McElhiney, Goldberg et al, and Tang et al. fails to establish a prima facie case of 
obviousness of independent Claim 49. 
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IX. Conclusion 

In view of the foregoing, Appellant submits that the rejections of Claims 1,6-15, 
20-28, 37, and 42-49 are improper and should not be sustained. Therefore, a reversal of 
the rejections in the final Office action dated November 16, 2009, is respectfully 
5 requested. 



Respectfully submitted, 



10 Dated: June 29. 2010 



Customer No. 89955 



/PAUL D. AMROZOWICZ/ 
Paul D. Amrozowicz 
Registration No. 45,264 
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X. CLAIMS APPENDIX 
Claims on Appeal 

1 . A program product, comprising: 

a) a database that is compatible with multiple end-user systems, the database 
comprising: 

a data section comprising a plurality of data tables, each data table 
including a plurality of data records that each have one or more features that 
affect its compatibility with one or more of the end-user systems, each data record 
including a feature field that contains one or more feature bits representative of 
each of its features; and 

a structure section comprising a plurality of feature mask tables, each 
feature mask table including a feature mask record for each of the multiple end- 
user systems that use one or more of the data tables that include the data records 
having one or more features, each feature mask record including one or more 
feature mask values that indicate whether the one or more features of a data 
record are compatible with one or more of the end-user systems, and thereby 
indicate whether the data record is compatible with one or more of the end-user 
systems; 

and 

b) at least one physical computer-readable medium having said database stored 
thereon. 

2-5 (canceled). 
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6. The program product of Claim 1, wherein the structure section further 
comprises a system identification table that includes data that uniquely identifies each of 
the end-user systems. 

7. The program product of Claim 6, wherein the system identification table 
comprises a plurality of system identification records, each system identification record 
associated with each of the end-user systems. 

8. The program product of Claim 1 , wherein: 

the structure section further comprises a table pointer table that includes data that 
uniquely describes at least each of the data tables. 

9. The program product of Claim 8, wherein: 

the table pointer table comprises a plurality of table pointer records; and 
at least one table pointer record is associated with each of the data tables. 

10. The program product of Claim 9, wherein each table pointer record 
includes data representative of at least: 

a location of the associated data table; 

a number of the data records in the associated table; and 

a size of each data record in the associated data table. 
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1 1 . The program product of Claim 1 , wherein: 

each data record includes a plurality of fields in addition to the feature field; and 
the structure section further comprises a field definition table that includes at least 
data representative of each of the data record fields. 

12. The program product of Claim 1 1 , wherein the structure section further 
comprises one or more return type tables, each return type table including data 
representative of a format of each of the data record fields. 

13. The program product of Claim 1 , further comprising: 

a header section that includes data representative of indicia that is used to identify 
the database. 

14. The program product of Claim 13, wherein the header section further 
includes data representative of a location of the structure section. 

15. A method of generating a database that is compatible with multiple end- 
user systems, the method comprising the steps of: 

generating a data section; 

storing a plurality of data records in the data section, each data record including a 
feature field; 

associating one or more features with each data record; 
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supplying each feature field with one or more feature bits that represent each of 
the features associated therewith; 

dividing the data section into a plurality of data tables that each include a plurality 
of the data records; 

generating a structure section that comprises a plurality of feature mask tables, 
each feature mask table including a feature mask record for each of the end-user systems 
that use one or more of the data tables that include the data records having one or more 
features; and 

including one or more feature mask values, in each feature mask record, that 
indicate whether the one or more features of a data record are compatible with one or 
more of the end-user systems, to thereby indicate whether the data record is compatible 
with one or more of the end-user systems. 

16-19 (canceled). 

20. The method of Claim 1 5, further comprising: 

generating a system identification table that includes data that uniquely identifies 
each of the end-user systems. 

2 1 . The method of Claim 20, further comprising: 

including a plurality of system identification records in the system identification 
table, each system identification record associated with each of the end-user systems. 
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22. The method of Claim 1 5, further comprising: 

generating a table pointer table that includes data that uniquely describes at least 
each of the data tables. 

23 . The method of Claim 22 further comprising: 

including a plurality of table pointer records in the table pointer table, at least one 
table pointer record is associated with each of the data tables. 

24. The method of Claim 23, further comprising: 

supplying each tabic pointer record with data representative of at least (i) a 
location of the associated data table, (ii) a number of the data records in the associated 
table and (iii) a size of each data record in the associated data table. 

25. The method of Claim 1 5, further comprising: 

including a plurality of fields, in addition to the feature field, in each data record; 

and 

generating a field definition table that includes at least data representative of each 
of the data record fields. 

26. The method of Claim 25, further comprising: 

generating one or more return type tables, each return type table including data 
representative of a format of each of the data record fields. 
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27. The method of Claim 15, further comprising: 

generating a structure section and including the feature mask therein; 
generating a header section; and 

supplying the header section with data representative of indicia that is used to 
identify the database. 

28. The method of Claim 27, wherein the header section further includes data 
representative of a location of the structure section. 

29-36 (canceled). 

37. A computer system, comprising: 
a processor; 

memory in operable communication with the processor; and 
a database stored in the memory, the database compatible with multiple end-user 
systems and including: 

a data section comprising a plurality of data tables, each data table 
including a plurality of data records that each have one or more features that 
affect its compatibility with one or more of the end-user systems, each data record 
including a feature field that contains one or more feature bits representative of 
each of its features, and 

a structure section comprising a plurality of feature mask tables, each 
feature mask table including a feature mask record for each of the multiple end- 
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user systems that use one or more of the data tables that include the data records 
having one or more features, each feature mask record including one or more 
feature mask values that indicate whether the one or more features of a data 
record are compatible with one or more of the end-user systems, and thereby 
5 indicate whether the data record is compatible with one or more of the end-user 

systems. 

38-41 (canceled). 

10 42. The system of Claim 37, wherein the structure section further comprises a 

system identification table that includes data that uniquely identifies each of the end-user 
systems. 

43. The system of Claim 42, wherein the system identification table comprises 
15 a plurality of system identification records, each system identification record associated 

with each of the end-user systems. 

44. The system of Claim 37, wherein: 

the structure section further comprises a table pointer table that includes data that 
20 uniquely describes at least each of the data tables. 

45 . The system of Claim 44, wherein: 

the table pointer table comprises a plurality of table pointer records; and 
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at least one table pointer record is associated with each of the data tables. 



46. The system of Claim 45, wherein each table pointer record includes data 
representative of at least: 

a location of the associated data table; 

a number of the data records in the associated table; and 

a size of each data record in the associated data table. 

47. The database of Claim 37, wherein: 

each data record includes a plurality of fields in addition to the feature field; and 
the structure section further comprises a field definition table that includes at least 
data representative of each of the data record fields. 

48. The system of Claim 47, wherein the structure section further comprises 
one or more return type tables, each return type table including data representative of a 
format of each of the data record fields. 

49. A flight management system, comprising: 
memory; 

a navigation database stored in the memory, the navigation database compatible 
with multiple flight management systems and including: 

a data section comprising a plurality of data tables, each data table 
including a plurality of navigational data records that each have one or more 
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features that affect its compatibility with one or more of the flight management 
systems, each data record including a feature field that contains one or more 
feature bits representative of each of its features, and 

a structure section a comprising a plurality of feature mask tables, each 
5 feature mask table including a feature mask record for each of the flight 

management systems that use one or more of the data tables that include the 
navigational data records having one or more features, each feature mask record 
including one or more feature mask values that indicate whether the one or more 
features of a navigational data record are compatible with one or more of the 
10 flight management systems, and thereby indicate whether the data record is 

compatible with one or more of the flight management systems; and 
a processor configured to generate an aircraft flight plan based at least in part on 
the navigational data stored in the navigation database. 
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XI. EVIDENCE APPENDIX 
No evidence pursuant to 37 C.F.R. §§ 1.130, 1.131, or 1.132 has been entered by 
the Examiner or relied upon by Appellant in the instant appeal beyond that which is 
already contained in the as-filed application, as is delineated in the Arguments section of 
5 this Brief. 
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XII. RELATED PROCEEDINGS APPENDIX 
As there are no related appeals and interferences, there are also no decisions 
rendered by a court or the Board of Patent Appeals and Interferences that are related to 
the instant appeal. 
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